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Abstract 
This document discusses some existing commonly used BGP mechanisms 
for Autonomous System Number (ASN) migration that are not formally 
part of the BGP4 protocol specification. It is necessary to document 
these de facto standards to ensure that they are properly supported 
in future BGP protocol work. 
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Introduction 


This document discusses some existing commonly used BGP mechanisms 
for Autonomous System Number (ASN) migration that are not formally 
part of the BGP4 [RFC4271] protocol specification. These mechanisms 


are local to a given 
or cooperation of BGP neighbors. 


BGP speaker and do not require negotiation with 
The deployment of these mechanisms 


do not need to interwork with one another to accomplish the desired 


results, 


so slight variations between existing vendor implementations 


exist and will not necessarily be harmonized due to this document. 


However, 


protocol enhancements to BGP that propose to read, copy, 


it is necessary to document these de facto standards to 


ensure that new implementations can be successful, and any future 


manipulate, 


or compare the AS_PATH attribute can do so without 


of these very widely used ASN migration mechanisms. 


The migration mechanisms discussed here are useful 
organizations of all sizes, but it is important to 


inhibiting the use 


to ISPs and 
understand the 


business need for these mechanisms and illustrate why they are so 
critical for ISPs’ operations. During a merger, acquisition, or 
divestiture involving two organizations it is necessary to seamlessly 
migrate both internal and external BGP speakers from one ASN to a 
second ASN. The overall goal in doing so is to simplify operations 
through consistent configurations across all BGP speakers in the 


combined network. In addition, given that the BGP 
algorithm selects routes with the shortest AS_PATH 
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critical that the ISP does not increase AS_PATH length during or 
after ASN migration, because an increased AS_PATH length would likely 
result in sudden, undesirable changes in traffic-patterns in the 
network. 


By default, the BGP protocol requires an operator to configure a 
router to use a single remote ASN for the BGP neighbor, and the ASN 
must match on both ends of the peering in order to successfully 
negotiate and establish a BGP session. Prior to the existence of 
these migration mechanisms, it would have required an ISP to 
coordinate an ASN change with, in some cases, tens of thousands of 
customers. In particular, as each router is migrated to the new ASN, 
to avoid an outage due to ASN mismatch, the ISP would have to force 
all customers on that router to change their router configurations to 
use the new ASN immediately after the ASN change. Thus, it was 
critical to define a more asymmetric migration method so that the ISP 
could seamlessly change the ASN within its network(s) but allow the 
customers to gradually migrate to the ISP’s new ASN when convenient. 
These customer migrations could occur either by coordinating 
individual session reconfigurations or, to allow for truly asymmetric 
migration, by accepting sessions using either the old or new ASN. 


1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


1.2. Documentation Note 


This document uses Autonomous System Numbers (ASNs) from the range 
reserved for documentation as described in RFC 5398 [RFC5398]. In 
the examples used here, they are intended to represent Globally 
Unique ASNs, not private use ASNs as documented in Section 5 of RFC 
6996 [RFC6996]. 


2. ASN Migration Scenario Overview 


The use case being discussed here is an ISP merging two or more ASNs, 
where eventually one ASN subsumes the other(s). In this use case, we 
will assume the most common case where there are two ISPs, A and B, 
that prior to the ASN migration use AS 64500 and 64510, respectively. 
AS 64500 will be the permanently retained ASN used across the 
consolidated set of both ISPs network equipment, and AS 64510 will be 
retired. Thus, at the conclusion of the ASN migration, there will be 
a single ISP A’ with all internal BGP speakers configured to use AS 
64500. To all external BGP speakers, the AS_PATH length will not be 
increased. 
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In this same scenario, AS 64496 and AS 64499 represent two separate 
customer networks: C and D, respectively. Originally, customer C (AS 
64496) is attached to ISP B, which will undergo ASN migration from AS 
64510 to AS 64500. Furthermore, customer D (AS 64499) is attached to 
ISP A, which does not undergo ASN migration since the ASN for ISP A 


will remain constant, (AS 64500). Although this example refers to AS 
64496 and 64499 as customer networks, either or both may be 
settlement-free or other types of peers. In this use case, they are 


referred to as "customers" merely for convenience. 


/ ISP A \ / ISP B\ 
| AS 64500 | | AS 64510 | 
\ / \ / 
| Cust D | | Cust C 
| AS 64499 | | AS 64496 | 


Figure 1: Before Migration 


/ \ 
| ISP A’ | 
| AS 64500 | 
\ / 
/ \ 
/ \ 
| | 
| Cust D | | Cust C | 
| AS 64499 | | as 64496 | 


Figure 2: After Migration 


The general order of operations, typically carried out in a single 
maintenance window by the network undergoing ASN migration (ISP B), 
is as follows. First, ISP B will change the global BGP ASN used by a 
Provider Edge (PE) router, from ASN 64510 to 64500. At this point, 
the router will no longer be able to establish External BGP (eBGP) 
sessions toward the existing Customer Edge (CE) devices that are 
attached to it and still using AS 64510. Second, since ISP B needs 
to do this without coordinating the simultaneous change of its ASN 
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with all of its eBGP peers, ISP B will configure two separate, but 
related ASN migration mechanisms discussed in this document on all 
eBGP sessions toward all CE devices. These mechanisms enable the 
router to establish BGP neighbors using the legacy ASN, modify the 
AS_PATH attribute received from a CE device when advertising it 
further, and modify AS_PATH when transmitted toward CE devices to 
achieve the desired effect of not increasing the length of the 
AS_PATH. 


At the conclusion of the ASN migration, the CE devices at the edge of 
the network are not aware of the fact that their upstream router is 
now in a new ASN and do not observe any change in the length of the 
AS_PATH attribute. However, after the changes discussed in this 
document are put in place by ISP A’, there is a change to the 
contents of the AS_PATH attribute to ensure the AS_PATH is not 
artificially lengthened while these AS migration parameters are used. 


In this use case, neither ISP is using BGP Confederations [RFC5065] 
internally. 


3. External BGP Autonomous System Migration Mechanisms 


The following section addresses optional capabilities that are 
specific to modifying the AS_PATH attribute at the Autonomous System 
Border Routers (ASBRs) of an organization (typically a single Service 
Provider). This ensures that external BGP customers/peers are not 
forced to make any configuration changes on their CE routers before 
or during the exact time the Service Provider wishes to migrate to a 
new, permanently retained ASN. Furthermore, these mechanisms 
eliminate the artificial lengthening of the AS_PATH both transmitted 
from and received by the Service Provider that is undergoing AS 
Migration, which would have negative implications on path selection 
by external networks. 


3.1. Modify Inbound BGP AS_PATH Attribute 


The first instrument used in the process described above is called 
"Local AS". This allows the router to supersede the globally 
configured ASN in the "My Autonomous System" field of the BGP OPEN 
[RFC4271] with a locally defined AS value for a specific BGP neighbor 
or group of neighbors. This mechanism allows the PE router that was 
formerly in ISP B to establish an eBGP session toward the existing CE 
devices using the legacy AS -- AS 64510. Ultimately, the CE devices 
(i.e., customer C) are completely unaware that ISP B has reconfigured 
its router to participate as a member of a new AS. Within the 
context of the former ISP B PE router, the second effect this 
specific mechanism has on AS_PATH is that, by default, it prepends 
all received BGP UPDATEs with the legacy AS of ISP B -- AS 64510 -- 
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while advertising it (Adj-RIB-Out) to other BGP speakers (A’). 
Within the Loc-RIB on ISP B prior to the migration, the AS_PATH of 
route announcements received from customer C would appear as 64496, 
whereas the same RIB on ISP A’ (ISP B routers post-migration) would 
contain AS_PATH 64510 64496. 


The second instrument, referred to as "No Prepend Inbound", is 
enabled on PE routers migrating from ISP B. The "No Prepend Inbound" 
capability causes ISP B’s routers to not prepend the legacy AS (AS 
64510), when advertising UPDATES received from customer C. This 
restores the AS_PATH within ISP A’ for route announcements received 
from customer C so that it is just one ASN in length: 64496. 


In the direction of CE -> PE (inbound): 


1. "Local AS": Allows the local BGP router to generate a BGP OPEN to 
an eBGP neighbor with the old, legacy ASN value in the "My 
Autonomous System" field. When this capability is activated, it 
also causes the local router to prepend the <old_ASN> value to 
the AS_PATH when installing or advertising routes received from a 
CE to Internal BGP (iBGP) neighbors inside the Autonomous System. 


2. "No Prepend Inbound (of Local AS)": The local BGP router does not 
prepend the <old_ASN> value to the AS_PATH when installing or 
advertising routes received from the CE to iBGP neighbors inside 
the Autonomous System 


PE-B is a PE that was originally in ISP B, and has a customer eBGP 
session to CE-B. PE-B has had its global configuration ASN changed 
from AS 64510 to AS 64500 to make it part of the permanently retained 
ASN. This now makes PE-B a member of ISP A’. PE-A is a PE that was 
originally in ISP A, and has a customer peer CE-A. Although its 
global configuration ASN remains AS 64500, throughout this exercise 
we also consider PE-A a member of ISP A’. 


ISP A’ ISP A’ 
CE-A <--- PE-A <-~------------------ PE-B <--- CE-B 
64499 New_ASN: 64500 O1ld_ASN: 64510 64496 


New_ASN: 64500 
Note: Direction of BGP UPDATE as per the arrows. 
Figure 3: Local AS and No Prepend BGP UPDATE Diagram 
As a result, using both the "Local AS" and "No Prepend Inbound" 
capabilities on PE-B, CE-A will see an AS_PATH of 64500 64496. CE-A 


will not receive a BGP UPDATE containing AS 64510 in the AS_PATH. 
(If only the "Local AS" mechanism was configured without "No Prepend 
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Inbound" on PE-B, then CE-A would have seen an AS_PATH of 64500 64510 
64496, which results in an unacceptable lengthening of the AS_PATH). 
Note: If there are still routers in the old ASN (64510), it is 
possible for them to accept these manipulated routes (i.e., those 
with 64510 removed from the AS_PATH by this command) as if they have 
not already passed through their ASN, potentially causing a loop, 
since BGP’s normal loop-prevention behavior of rejecting routes that 
include its ASN in the path will not catch these. Careful filtering 
between routers remaining in the old ASN and routers migrated to the 
new ASN is necessary to minimize the risk of routing loops. 


3.2. Modify Outbound BGP AS_PATH Attribute 


The two aforementioned mechanisms, "Local AS" and "No Prepend 
Inbound", only modify the AS_PATH attribute received by the ISP’s PEs 
in the course of processing BGP UPDATEs from CE devices when CE 
devices still have an eBGP session established with the ISPs legacy 
AS (AS64510). 


In some existing implementations, "Local AS" and "No Prepend Inbound" 
do not concurrently modify the AS_PATH attribute for BGP UPDATEs that 
are transmitted by the ISP’s PEs to CE devices. In these 
implementations, with "Local AS" and "No Prepend Inbound" used on 
PE-B, there is an automatic lengthening of the AS_PATH in outbound 
BGP UPDATEs from ISP A’ toward directly attached eBGP speakers 
(customer C in AS 64496). The externally observed result is that 
customer C in AS 64496 will receive the following AS_PATH: 64510 
64500 64499. Therefore, if ISP A’ takes no further action, there 
will be an unacceptable increase in the AS_PATH length within the 
customer’s networks directly attached to ISP A’. 


A tertiary mechanism, referred to as "Replace Old AS", is used to 
resolve this problem. This capability allows ISP A’ to prevent 
routers from appending the globally configured ASN in outbound BGP 
UPDATES toward directly attached eBGP neighbors that are using the 
"Local AS" mechanism. Instead, only the old (or previously used) AS 
will be prepended in the outbound BGP UPDATE toward the customer’s 
network, restoring the AS_PATH length to what it what was before AS 
Migration occurred. 
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To reuse the above diagram, but in the opposite direction, we have: 


ISP A’ ISP A’ 
CE-A ---> PE-A ------------------- > PE-B ---> CE-B 
64499 New_ASN: 64500 O1d_ASN: 64510 64496 


New_ASN: 64500 
Note: Direction of BGP UPDATE as per the arrows. 
Figure 4: Replace AS BGP UPDATE Diagram 


By default, without the use of "Replace Old AS", CE-B would see an 
AS_PATH of 64510 64500 64499. After ISP A’ changes PE-B to use 
"Replace Old AS", CE-B would receive an AS_PATH of 64510 64499, which 
is the same AS_PATH length pre-AS migration. 


3.3. Implementation 


The mechanisms introduced in this section MUST be configurable ona 
per-neighbor or per-neighbor-group basis to allow for maximum 
flexibility. (Here, "neighbor group" refers to a group of similar 
BGP neighbor statements that reuse some common configuration to 
simplify provisioning.) When the "Local AS" capability is used, a 
local ASN will be provided in the configuration that is different 
from the globally configured ASN of the BGP router. To implement 
this mechanism, a BGP speaker SHOULD send BGP OPEN [RFC4271] (see 
Section 4.2) messages to the configured eBGP peer(s) using the local 
ASN configured for this session as the value sent in "My Autonomous 
System". The BGP router SHOULD NOT use the ASN configured globally 
within the BGP process as the value sent in "My Autonomous System" in 
the OPEN message. This prevents causing the eBGP neighbor to 
unnecessarily generate a BGP OPEN Error message "Bad Peer AS". This 
method is typically used to re-establish eBGP sessions with peers 
expecting the legacy ASN after a router has been moved to a new ASN. 


Implementations MAY support a more flexible model where the eBGP 
speaker attempts to open the BGP session using either the ASN 
configured as "Local AS" or the globally configured AS as discussed 
in BGP Alias (Section 4.2). If the session is successfully 
established to the globally configured ASN, then the modifications to 
AS_PATH described in this document SHOULD NOT be performed, as they 
are unnecessary. The benefit to this more flexible model is that it 
allows the remote neighbor to reconfigure to the new ASN without 
direct coordination between the ISP and the customer. 


Note that this procedure will vary slightly if the locally or 
globally configured ASN is a 4-octet ASN. See Section 3 of 
[RFC6793]. 
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4. 


When the BGP router receives UPDATEs from its eBGP neighbor 
configured with the "Local AS" mechanism, it processes the UPDATE as 
described in RFC4271 Section 5.1.2 [RFC4271]. However, the presence 
of a second ASN due to "Local AS" adds the following behavior to 
processing UPDATES received from an eBGP neighbor configured with 
this mechanism: 


1. Internal: The router SHOULD append the configured "Local AS" ASN 
in the AS_PATH attribute before installing the route or 
advertising the UPDATE to an iBGP neighbor. The decision of when 
to append the ASN is an implementation detail outside the scope 
of this document. Some considerations factoring into this 
decision include consistency in the AS_PATH throughout the AS, 
and implementation of the loop detection mechanism. 


2. External: The BGP router SHOULD first append the globally 
configured ASN to the AS_PATH immediately followed by the "Local 
AS" value before advertising the UPDATE to an eBGP neighbor. 


Two options exist to manipulate the behavior of the basic "Local AS" 
mechanism. They modify the behavior as described below: 


1. "No Prepend Inbound": When the BGP router receives inbound BGP 
UPDATEs from its eBGP neighbor configured with this option, it 
MUST NOT append the "Local AS" ASN value in the AS_PATH attribute 
when installing the route or advertising that UPDATE to iBGP 
neighbors, but it MUST still append the globally configured ASN 
as normal when advertising the UPDATE to other local eBGP 
neighbors (i.e., those natively peering with the globally 
configured ASN). 


2. "Replace Old AS" (outbound): When the BGP router generates 
outbound BGP UPDATES toward an eBGP neighbor configured with this 
option, the BGP speaker MUST NOT append the globally configured 
ASN from the AS_PATH attribute. The BGP router MUST append only 
the configured "Local AS" ASN value to the AS_PATH attribute 
before sending the BGP UPDATEs outbound to the eBGP neighbor. 


Internal BGP Autonomous System Migration Mechanisms 


The following section describes mechanisms that assist with a gradual 
and least service-impacting migration of Internal BGP sessions from a 
legacy ASN to the permanently retained ASN. The following mechanism 
is very valuable to networks undergoing AS migration, but its use 
does not cause changes to the AS_PATH attribute. 
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4.1. Internal BGP AS Migration 


In this case, all of the routers to be consolidated into a single, 
permanently retained ASN are under the administrative control of a 
single entity. Unfortunately, the traditional method of migrating 
all Internal BGP speakers, particularly within larger networks, is 
both time-consuming and widely service impacting. 


The traditional method to migrate Internal BGP sessions was strictly 
limited to reconfiguration of the global configuration ASN and, 
concurrently, changing all iBGP neighbors’ remote ASN from the legacy 
ASN to the new, permanently retained ASN on each router within the 
legacy AS. These changes can be challenging to swiftly execute in 
networks with more than a few dozen internal BGP routers. There are 
also the concomitant service interruptions as these changes are made 
to routers within the network, resulting in a reset of iBGP sessions 
and subsequent route reconvergence to reestablish optimal routing 
paths. Operators often cannot make such sweeping changes given the 
associated risks of a highly visible service interruption; rather, 
they require a more gradual method to migrate Internal BGP sessions, 
from one ASN to a second, permanently retained ASN, that is not 
visibly service impacting to its customers. 


With the "Internal BGP AS Migration" mechanism described herein, it 
allows an Internal BGP speaker to form a single iBGP session using 
either the old, legacy ASN or the new, permanently retained ASN. The 
benefits of using this mechanism are several fold. First, it allows 
for a more gradual and less service-impacting migration away from the 
legacy ASN to the permanently retained ASN. Second, it (temporarily) 
permits the coexistence of the legacy and permanently retained ASN 
within a single network, allowing for uniform BGP path selection 
among all routers within the consolidated network. 


The iBGP router with the "Internal BGP AS Migration" capability 
enabled allows the receipt of a BGP OPEN message with either the 
legacy ASN value or the new, globally configured ASN value in the "My 
Autonomous System" field of the BGP OPEN message from iBGP neighbors. 
It is important to recognize that enablement of the "Internal BGP AS 
Migration" mechanism preserves the semantics of a regular iBGP 
session (i.e., using identical ASNs). Thus, the BGP attributes 
transmitted by and the acceptable methods of operation on BGP 
attributes received from iBGP sessions configured with "Internal BGP 
AS Migration" capability are no different than those exchanged across 
an iBGP session without "Internal BGP AS Migration" configured, as 
defined by [RFC4271] and [RFC4456]. 
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Typically, in medium to large networks, BGP Route Reflectors (RRs) 
[RFC4456] are used to aid in reduction of configuration of iBGP 
sessions and scalability with respect to overall TCP (and BGP) 
session maintenance between adjacent iBGP routers. Furthermore, BGP 
Route Reflectors are typically deployed in pairs within a single 
Route Reflection cluster to ensure high reliability of the BGP 
Control Plane. As such, the following example will use Route 
Reflectors to aid in understanding the use of the "Internal BGP AS 
Migration" mechanism. Note that Route Reflectors are not a 
prerequisite to enable "Internal BGP AS Migration" and this mechanism 
can be enabled independent of the use of Route Reflectors. 


The general order of operations is as follows: 


1. Within the legacy network, (the routers comprising the set of 
devices that still have a globally configured legacy ASN), one 
member of a redundant pair of RRs has its global configuration 
ASN changed to the permanently retained ASN. Concurrently, the 
"Internal BGP AS Migration" capability is enabled on all iBGP 
sessions on that device. This will comprise Non-Client iBGP 
sessions to other RRs as well as Client iBGP sessions, typically 
to PE devices, both still utilizing the legacy ASN. Note that 
during this step there will be a reset and reconvergence event on 
all iBGP sessions on the RRs whose configuration was modified; 
however, this should not be service impacting due to the use of 
redundant RRs in each RR Cluster. 


2. The above step is repeated for the other side of the redundant 
pair of RRs. The one alteration to the above procedure is that 
the "Internal BGP AS Migration" mechanism is now removed from the 
Non-Client iBGP sessions toward the other (previously 
reconfigured) RRs, since it is no longer needed. The "Internal 
BGP AS Migration" mechanism is still required on all RRs for all 
RR Client iBGP sessions. Also during this step, there will be a 
reset and reconvergence event on all iBGP sessions whose 
configuration was modified, but this should not be service 
impacting. At the conclusion of this step, all RRs will have 
their globally configured ASN set to the permanently retained ASN 
and "Internal BGP AS Migration" enabled and in use toward RR 
Clients. 


3. At this point, the network administrators would then be able to 
establish iBGP sessions between all Route Reflectors in both the 
legacy and permanently retained networks. This would allow the 
network to appear to function, both internally and externally, as 
a single, consolidated network using the permanently retained 
network. 
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4. To complete the AS migration, each RR Client (PE) in the legacy 

network still utilizing the legacy ASN is now modified. 
Specifically, each legacy PE would have its globally configured 
ASN changed to use the permanently retained ASN. The ASN 


configured within the PE for the iBGP sessions toward each RR 


would be changed to use the permanently retained ASN. It is 
unnecessary to enable the "Internal BGP AS Migration" mechanism 
on these migrated iBGP sessions. During the same maintenance 


window, External BGP sessions would be modified to include the 
above "Local AS", "No Prepend", and "Replace Old AS" mechanisms 
described in Section 3 above, since all of the changes are 
service interrupting to the eBGP sessions of the PE. At this 
point, all PEs will have been migrated to the permanently 
retained ASN. 


5. The final step is to excise the "Internal BGP AS Migration" 
configuration from the Router Reflectors in an orderly fashion. 
After this is complete, all routers in the network will be using 
the new, permanently retained ASN for all iBGP sessions with no 
vestiges of the legacy ASN on any iBGP sessions. 


The benefit of using the aforementioned "Internal BGP AS Migration" 
capability is that it is a more gradual and less externally service 
impacting change to accomplish an AS migration. Previously, without 
"Internal BGP AS Migration", such an AS migration change would carry 
a high risk and need to be successfully accomplished in a very short 
time frame (e.g., at most several hours). In addition, it would 
likely cause substantial routing churn and rapid fluctuations in 
traffic carried -- potentially causing periods of congestion and 
resultant packet loss -- during the period when the configuration 
changes are underway to complete the AS Migration. On the other 
hand, with "Internal BGP AS Migration", the migration from the legacy 
ASN to the permanently retained ASN can occur over a period of days 
or weeks with reduced customer disruption. (The only observable 
service disruption should be when each PE undergoes the changes 
discussed in step 4 above.) 


4.2. Implementation 


The mechanism introduced in this section MUST be configurable ona 
per-neighbor or per-neighbor-group basis to allow for maximum 
flexibility. When configured with this mechanism, a BGP speaker MUST 
accept BGP OPEN and establish an iBGP session from configured iBGP 
peers if the ASN value in "My Autonomous System" is either the 
globally configured ASN or a locally configured ASN provided when 
this capability is utilized. Additionally, a BGP router configured 
with this mechanism MUST send its own BGP OPEN [RFC4271] (see 

Section 4.2) using either the globally configured or the locally 
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configured ASN in "My Autonomous System" as follows. To avoid 
potential deadlocks when two BGP speakers are attempting to establish 
a BGP peering session and are both configured with this mechanism, 
the speaker SHOULD send BGP OPEN using the globally configured ASN 
first, and only send a BGP OPEN using the locally configured ASN as a 
fallback if the remote neighbor responds with the BGP error "Bad Peer 
AS". In each case, the BGP speaker MUST treat UPDATES sent and 
received to this peer as if this was a natively configured iBGP 
session, as defined by [RFC4271] and [RFC4456]. 


Note that this procedure will vary slightly if the locally or 
globally configured ASN is a 4-octet ASN. See Section 3 of 
[RFC6793]. 


5. Additional Operational Considerations 


This document describes several mechanisms to support ISPs and other 
organizations that need to perform ASN migrations. Other variations 
of these mechanisms may exist, for example, in legacy router software 
that has not been upgraded or reached End of Life, but continues to 
operate in the network. Such variations are beyond the scope of this 
document. 


Companies routinely go through periods of mergers, acquisitions, and 
divestitures, which in the case of the former cause them to 
accumulate several legacy ASNs over time. ISPs often do not have 
control over the configuration of customers’ devices (i.e., the ISPs 
are often not providing a managed CE router service, particularly to 
medium and large customers that require eBGP). Furthermore, ISPs are 
using methods to perform ASN migration that do not require 
coordination with customers. Ultimately, this means there is not a 
finite period of time after which legacy ASNs will be completely 
expunged from the ISP’s network. In fact, it is common that legacy 
ASNs and the associated External BGP AS Migration mechanisms 
discussed in this document can and do persist for several years, if 
not longer. Thus, it is prudent to plan that legacy ASNs and 
associated External BGP AS Migration mechanisms will persist in an 
operational network indefinitely. 


With respect to the Internal BGP AS Migration mechanism, all of the 
routers to be consolidated into a single, permanently retained ASN 
are under the administrative control of a single entity. Thus, 
completing the migration from iBGP sessions using the legacy ASN to 
the permanently retained ASN is more straightforward and could be 
accomplished in a matter of days to months. Finally, good 
operational hygiene would dictate that it is good practice to avoid 
using "Internal BGP AS Migration" capability over a long period of 
time for reasons of not only operational simplicity of the network, 
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but also reduced reliance on that mechanism during the ongoing life 
cycle management of software, features, and configurations that are 
maintained on the network. 


6. Security Considerations 


This document discusses a process by which one ASN is migrated into 
and subsumed by another. This involves manipulating the AS_PATH 
attribute with the intent of not increasing the AS_PATH length, which 
would typically cause the BGP route to no longer be selected by BGP’s 
Path Selection Algorithm in others’ networks. This could result in 
sudden and unexpected shifts in traffic patterns in the network, 
potentially resulting in congestion. 


Given that these mechanisms can only be enabled through configuration 
of routers within a single network, standard security measures should 
be taken to restrict access to the management interface(s) of routers 
that implement these mechanisms. Additionally, BGP sessions SHOULD 
be protected using TCP Authentication Option [RFC5925] and the 
Generalized TTL Security Mechanism [RFC5082] 
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Appendix A. Implementation Report 


As noted elsewhere in this document, this set of migration mechanisms 
has multiple existing implementations in wide use. 


o Cisco [CISCO] 
o Juniper [JUNIPER] 
o Alcatel-Lucent [ALU] 


This is not intended to be an exhaustive list, as equivalent features 
do exist in other implementations; however, the authors were unable 
to find publicly available documentation of the vendor-specific 
implementation to reference. 
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